Exposed getblocktemplate rpc via REST endpoint.#230
Conversation
| json_response(query.estimate_fee_map(), TTL_SHORT) | ||
| } | ||
|
|
||
| (&Method::GET, Some(&"getblocktemplate"), None, None, None, None) => { |
There was a problem hiding this comment.
Suggest doing something more like /block-template instead so it looks less like an RPC passthrough (can give us flexibility in the future to change the object returned).
| result: errors::Result<JsonValue>, | ||
| ) -> Result<Response<Full<Bytes>>, HttpError> { | ||
| match result { | ||
| Ok(template) => json_response(template, GETBLOCKTEMPLATE_TTL as u32), |
There was a problem hiding this comment.
we probably want to document that the endpoint is for block explorers and not mining work as the 15 second staleness could be an issue there.
| } | ||
| } | ||
|
|
||
| fn getblocktemplate_rpc_error(err: &errors::Error) -> Option<(i64, String)> { |
There was a problem hiding this comment.
Codex review finding:
The Connection error handling here probably will not behave as intended.
Daemon::request() retries ErrorKind::Connection internally, so this REST error path is unlikely to see those errors.
For example, bitcoind warmup error -28 is converted into ErrorKind::Connection, which means /getblocktemplate would keep retrying instead of returning the intended 502 JSON response.
One related concern: Query::getblocktemplate() holds the block template cache mutex while making the daemon RPC call. If that RPC gets stuck retrying, later /getblocktemplate requests will block behind the same mutex.
There was a problem hiding this comment.
Overall looks pretty good. Currently I don't think that electrs directly proxies through any other calls to bitcoin node (although I was just considering it for calls to GET /block//raw... so electrs doesn't cache all the txs in the raw block).
We might also consider adding a startup flag (--enable-mining-rest) to enable this.
6f61218 to
a812004
Compare
No description provided.